當我們在配置 pod.spec.containers.resources.requests 以及 pod.spec.containers.resources.limits 的時候，會有兩個誤解，接下來文章會針對這兩個誤解說明。

誤解 1：pod.spec.containers.resources.requests 只有在排程的時候有效。

前面有提到，kube-scheduler 會在 filter 階段的時候過濾掉沒有足夠 Allocatable resource 的 Node，如果 Node 的 Allocatable resource 沒辦法滿足 pod.spec.containers.resources.requests，就會在 filter 階段過濾掉。

這是大多數人在分配 pod.spec.containers.resources.requests 要考慮到的因素，因為這會影響 Pod 能不能被排程到 Node 上面。

但是，pod.spec.containers.resources.requests 影響到的不只是排程，還包含運行時的資源分配。

你在 pod.spec.containers.resources.requests → CRI → OCI → cgroup

這樣的路徑，最終會落到 kernel 的 cgroup，影響 cgroup 控制資源分配的方式。

我們統一以 cgroup v2 來解釋，因為我覺得 v2 的命名比較直觀。

如果有三個Pod，Pod1, Pod2, Pod3，pod.spec.containers.resources.request.cpu 設定為 200m, 200m, 400m

cgroup v2 以 cpu.weight 表示一個 container 可以用多少比例的時間，預設為 100ms

而這 100ms 單位，會根據比例，以這為例也就是 200:200:400 → 1:1:2，所以 Pod1:Pod2:Pod3 最終在這個 CFS period 分配到的時間是 25ms:25ms:50ms。

pod.spec.containers.resources.limits.cpu 會需要討論 CPU throttling ，所以我們明天繼續說第二個誤解：pod.resources.limits 只要比 usage 還要高就不會有事。

最後我還是跳進去 cgroups 這一個大坑，希望可以好好的講清楚